OpenEdge Development:<br />Progress Dynamics Basic Development SDO logic procedure

As described in the standard ADM2 product documentation, table maintenance logic should go into the SDO defined for each table. In this way it will be executed whenever the user makes an update through the SDO, regardless of the nature of the interface. However, you do not need to take this dictum literally. Even in standard SDOs, you can easily put your table maintenance logic in a separate procedure (perhaps leave it in an existing procedure from your current application if the calling mechanism can be worked out), and run it from inside the standard hooks in the SDO.

For example, the preTransactionValidate procedure run just before the database transaction starts could simply turn around and call something else. Here is one example of what such code could look like. Note that if you were going to do this on a wide scale, it would be wise to develop a standard technique, perhaps using an include file, to wrap the old code in the new call. The standard SDO update buffer, RowObjUpd, is copied to a standard Customer buffer on the assumption that the existing procedure expects that buffer with no additional fields.

The bOldCustomer buffer gets the original version of the record, as it was read from the database, as follows:

PROCEDURE preTransactionValidate: DEFINE BUFFER bCustomer LIKE Customer. DEFINE BUFFER bOldCustomer LIKE Customer. DEFINE BUFFER bRowObjUpd LIKE RowObjUpd. FOR EACH RowObjUpd `WHERE` RowObjUpd.RowMod = ‘U’: BUFFER-COPY RowObjUpd TO bCustomer. FIND bRowObjUpd `WHERE` bRowObjUpd.RowNum = RowObjUpd.RowNum AND bRowObjUpd.RowMod = ‘’. /* Blank indicates the Before copy. */ BUFFER-COPY bRowObjUpd TO bOldCustomer. RUN CustomerLogic.p (INPUT bCustomer, INPUT bOldCustomer, OUTPUT cStatusMessage). IF cStatusMessage NE “” THEN RETURN cStatusMessage. END.

PROCEDURE preTransactionValidate: 
DEFINE BUFFER bCustomer  LIKE Customer. 
DEFINE BUFFER bOldCustomer LIKE Customer. 
DEFINE BUFFER bRowObjUpd LIKE RowObjUpd. 
FOR EACH RowObjUpd WHERE RowObjUpd.RowMod = ‘U’: 
  BUFFER-COPY RowObjUpd TO bCustomer. 
  FIND bRowObjUpd WHERE bRowObjUpd.RowNum = RowObjUpd.RowNum AND 
    bRowObjUpd.RowMod = ‘’. /* Blank indicates the Before copy. */ 
  BUFFER-COPY bRowObjUpd TO bOldCustomer. 
  RUN CustomerLogic.p (INPUT bCustomer, INPUT bOldCustomer,  
    OUTPUT cStatusMessage). 
  IF cStatusMessage NE “” THEN RETURN cStatusMessage. 
END.

This simplified example illustrates a couple of the shortcomings of the standard SDO logic definition. First, it requires a bit of extra work to associate the standard validation hooks with logic that is actually defined in another procedure. Second, the “wrapper” code that makes the association has some SDO-specific conventions in it.

If you define your logic directly in the SDO, your code has these same conventions:

Using the SDO buffer named RowObjUpd, and using the extra fields RowMod and RowNum to identify which type of update operation (Update, Add, Copy, Delete) has occurred.

Identifying the before version of each updated row.

Being prepared to loop through the table in the event that more than one record was changed in a single call.

The Progress Dynamics Version of SDOs is entirely compatible with existing ones, but it contains some enhancements to remove these SDO-specific logic elements. The goal is to make your logic more reusable and more flexible in how it is called.

When dynamic SDOs are generated in the Object Generator, a logic procedure is created that contains all validation logic that is associated with the SDO and becomes a super procedure.

This makes it easier to call the same table maintenance logic from elsewhere in your application, where you might not be using SDOs as a data management mechanism. In this way, you can truly use the same logic from everywhere regardless of the nature of the code.

The following illustrations might help to explain the position of the logic procedure in the Progress Dynamics architecture. The client application starts the SDO along with other client-side objects. Because there is no database connection on the client, the proxy version of the SDO is run. It, in turn, identifies the logical name of the partition in which its server-side counterpart should run, and starts the full SDO in that AppServer session.

Data is read from the database into the server-side RowObject table and passed across the AppServer connection to the client, where it is made available to other client objects. Updates made on the client are collected in a separate copy of the SDO temp-table called RowObjUpd and passed back to the server, where the data is validated and written back to the database. You can code validation logic into the SDO procedure. Using the DB-REQUIRED technique described above determines whether a particular logic procedure is compiled into the proxy and server-side SDOs or into the server-side full SDO only.

In Progress Dynamics, a new pair of procedures is generated to hold specific business logic for the table. As with the SDO, there is really only one procedure that has any code in it: the same kind of client proxy wrapper procedure is used to allow the same source procedure to be compiled two ways, with or without the internal procedure and functions that require the database connection. Since the logic procedure is started as a super procedure of the SDO, its contents more or less transparently become part of the SDO, so that the same validation procedures can go into the logic procedure as previously went into the SDO. If you create a logic procedure for an existing SDO and simply copy all of the standard validation procedures into it, the SDO will work exactly the same as it did before.

The resulting setup looks like the illustration in Figure 10–6. The logic procedures are started automatically by the SDOs on each side. The name of the logic procedure is a new property of the SDO. All validation logic goes into the logic procedure to be run on one side of the AppServer connection or the other. (As with SDOs themselves, this all works correctly if there is no AppServer at all. In that case, the server-side full SDO and logic object run on the client, with a local database connection.)

Updates are collected on the client in the RowObjUpd table as before. New supporting code for the SDO makes these records available to the logic procedure.

One of the principal reasons for separating out the logic procedure is to allow the SDO itself to become a run-time instance of a generic SDO, both on client and server. With no table-specific logic in the SDO itself, this becomes a relatively easy matter. Figure 10–7 shows this process.